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1.  Introduction 


Software-defined  radios  (SDRs)  provide  researchers  with  a  powerful  and  flexible  wireless 
communications  experimentation  platform.  GNU  Radio  is  the  most  popular  open-source 
software  toolkit  for  deploying.  Every  SDR  is  comprised  of  software  and  hardware.  In  this 
document,  we  consider  GNU  Radio  software  coupled  with  Universal  Software  Radio 
Peripheral  (USRP)  hardware.  In  GNU  Radio,  C++  blocks  perform  specific  signal 
processing  processing  tasks,  while  Python  applications  connect  the  blocks  together  to 
form  a  functional  software  radio.  For  example,  a  basic  transmitter  can  be  implemented  by 
using  Python  to  connect  the  following  C++  blocks  (which  already  exist  in  the  GNU  Radio 
software  library)  together:  modulator,  mixer,  and  amplifier. 

Each  block  specifies  its  input  and  output  requirements,  both  in  number  and  type.  For 
example,  the  gr_add_cc  block  adds  two  complex  input  streams  and  copies  the  results  onto 
one  complex  output  stream.  Blocks  are  generally  implemented  in  C++  for  computational 
efficiency,  but  other  possibilities  exist  (see  below). 

After  writing  a  new  block,  a  process  is  needed  to  expose  these  C++  blocks  for  use  by 
Python  scripts.  GNU  Radio  uses  the  Simplified  Wrapper  and  Interface  Generator  (SWIG), 
to  generate  the  necessary  components  to  make  C++  blocks  accessible  from  Python. 

From  the  standpoint  of  Python  applications,  each  block  consumes  its  input  stream(s), 
performs  a  specific  task,  and  generates  output  stream(s).  As  long  as  the  connections 
between  blocks  are  compatible,  there  is  no  restriction  to  how  many  blocks  can  be  chained 
together.  A  single  output  stream  can  connect  to  multiple  input  streams,  but  multiple 
outputs  cannot  connect  to  a  single  input  clue  to  ambiguity.  A  multiplexer  can  be  used  in 
such  a  situation  by  interleaving  many  inputs  onto  a  single  output. 

In  summary,  the  stages  of  block  creation  in  GNU  Radio  are  the  following: 

1.  Implementation  of  blocks  (C++),  the 
(.h,  .cc)  hies 

2.  Creation  of  SWIG  interfaces  between  C++/Python,  the 
(.i)  hie 

3.  Installation  of  blocks  into  a  shared  library 

4.  Usage  of  blocks  in  an  application  (Python),  the 
(.py)  hie 
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In  this  report,  we  detail  steps  1-4.  This  report  is  an  updated  and  expanded  presentation  of 
the  material  found  in 

http:  /  /  www.gnu.org/ software  /  gnuradio/doc /howto- write-a-block.html. 


2.  Implementation  of  Blocks 

Before  diving  into  block  implementation,  we  first  introduce  the  naming  conventions  of 
GNU  Radio  in  section  2.1.  Section  2.2  introduces  the  most  commonly  used  data  types,  and 
section  2.3  steps  through  the  essential  elements  of  block  creation  by  using  the  illustrative 
example  of  gr_block. 

2.1  Naming  Conventions 

There  are  several  strongly  followed  conventions  in  GNU  Radio,  and  a  familiarity  with  these 
expedites  code  writing  and  understanding. 

•  All  words  in  identifiers  are  separated  by  an  underscore,  e.g.,  gr_vector_int. 

•  All  types  in  the  GNU  Radio  package  are  preceded  by  gr,  e.g.,  gr_float. 

•  All  class  variables  are  preceded  with  d_,  e.g.,  d_min_streams. 

•  Each  classes  is  implemented  in  a  separate  hie,  e.g.,  class  gr_magic  is  implemented  in 
gr_magic .  cc  with  the  header  hie  gr_magic .  h. 

•  All  signal  processing  blocks  contain  their  input  and  output  types  in  their  suffixes, 
e.g.,  gr_fft_vcc  requires  complex  inputs  and  complex  outputs.  The  major  types  are 
hoat  (/),  complex  (c),  short  (s),  integer  (?,).  Any  type  may  be  vectorized  (v). 

2.2  Data  Types 

GNU  Radio  type  defines  the  most  commonly  used  data  types  to  a  set  of  names.  The  main 
purpose  of  this  is  to  create  a  common  set  of  conventions  for  naming  of  data  types.  The  list 
is  as  follows: 

typedef  std: : complex<f loat>  gr_complex; 

typedef  std: : complex<double>  gr_coraplexd; 

typedef  std: :vector<int>  gr_vector_int ; 

typedef  std: :vector<float>  gr_vector_f loat ; 
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typedef  std: : vector<double>  gr_vector_double ; 

typedef  std: :vector<void  *>  gr_vector_void_star ; 

typedef  std: : vector<const  void  *>  gr_vector_const_void_star ; 

typedef  short  gr_intl6; 

typedef  int  gr_int32; 

typedef  unsigned  short  gr_uintl6; 

typedef  unsigned  int  gr_uint32; 

2.2.1  Block  Signatures 

A  block  signature  is  simply  a  specification  of  the  data  types  that  enter  and  exit  a  signal 
processing  block.  In  list  1,  we  can  examine  gr_io_signature .  h  for  more  detail. 

1 
2 

3 

4 

5 

6 

7 

8 
9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

It  is  important  to  realize  that  our  block  has  two  signatures,  one  for  the  input  interface  and 
one  for  the  output  interface.  The  header  file  makes  it  clear  that,  for  a  given  interface, 
gr_io_signature  defines  the  minimum  and  maximum  number  of  streams  flowing  through 
that  interface,  as  well  as  the  number  of  bytes  in  a  single  element  of  the  stream.  Recall  that 
Python  is  used  to  connect  multiple  signal  processing  blocks  together.  The  main  purpose  of 
signatures  is  so  Python  can  raise  an  error  for  improper  connections. 


Listing  1.  gr_io_signature.h 

class  gr_io_signature  { 

int  d _ min _ streams  ; 

int  d _ max _ streams; 

std  :  :  vector<int>  d_sizeof_stream_item ; 

gr _ io _ signature  ( int  min _ streams,  int  max _ streams, 

const  std  :  :  vector<int>  &sizeof_stream  items )  ; 

friend  gr  io_signature_sptr 
gr_make_io  signaturev  ( int  min  streams , 

int  max _ streams  , 

const  std  : :  vector<int>  &sizeof  stream  items)  ; 

public  : 

static  const  int  IO„INFINITE  =  —1; 

—gr  io  signature  (); 

int  min  streams  ()  const  {  return  d  min  streams ;  } 
int  max_streams  ()  const  {  return  d_max_streams ;  } 
int  sizeof  stream  item  (int  index)  const; 
std  :  :  vector<int>  sizeof_stream_items  ( )  const; 

}; 
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The  following  are  examples  of  improper  connections: 


•  Too  {many/few}  {input/output}  connections  for  a  block 

•  Type  mismatch,  e.g.,  gr_complex  output  connected  to  gr_intl6  input 

2.2.2  Boost  Pointers 

GNU  Radio  uses  Boost  smart  pointers  instead  of  regular  C++  pointers.  Boost  is  a 
high-quality  software  library  with  many  extensions  to  the  basic  C++  language.  For  our 
purposes,  Boost  provides  a  smart  implementation  of  C++  pointers  that  offers  garbage 
collection,  i.e. ,  it  deletes  dynamically  allocated  objects  when  they  are  no  longer  needed. 
This  simplifies  our  implementation  efforts  and  improves  block  performance.  There  are 
actually  many  different  types  of  smart  pointers,  but  GNU  radio  uses  just  one  of  them, 
called  a  shared_ptr,  which  is  used  specifically  when  our  dynamically  allocated  object  has 
ownership  shared  by  several  pointers. 

In  order  to  declare  a  regular  C++  pointer  to  an  object  of  type  gr_io_signature,  we 
would  use  the  followig  command: 


gr_io_signature*  ptr; 


Whereas  with  Boost,  we  would  use  this  command: 


typedef  boost: : shared_ptr<gr_io_signature>  gr_io_signature_sptr ; 
gr_io_signature_sptr  ptr; 


to  declare  a  Boost  shared  pointer. 

As  shown  in  the  above  code,  GNU  Radio  uses  the  convention  of  type  defining  Boost  smart 
pointers  to  an  object  of  type  X  as  X_sptr.  This  format  makes  it  explicit  to  the  user  that 
X_sptr  is  a  Boost  smart  pointer. 

2.3  Case  Study:  gr _ block 

GNU  Radio  makes  extensive  use  of  the  notion  of  “inheritance,”  an  object  oriented  (00) 
programming  technique.  For  us,  this  simply  means  that  every  signal  processing  block  is  a 
specialization  of  a  general,  high-level  block,  which  GNU  Radio  calls  gr_block.  Our  task  is 
to  fill  in  the  details  of  gr_block  (referred  to  in  00-speak  as  “deriving  from  the  base 
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class”)  to  create  our  own  custom  block.  It  is  prudent  to  begin  our  study  of  writing  a  new 
block  by  first  examining  gr_block.h. 

The  class  gr_block  is  itself  derived  from  the  class  gr_basic_block.h.  We  consider  a  few 
of  the  fields  that  are  of  particular  interest  to  programmer  and  discuss  the  fields  inherited 
from  gr_basic_block. h  and  defined  gr_block.h  (lists  2  and  3).  The  entire  gr_block.h 
file  is  shown  in  appendix  A. 


Listing  2.  gr_basic_  block. h 


70 

std  :  :  string 

d_name ; 

71 

grio  signature  sptr 

d_input_signature  ; 

72 

grio  signature  sptr 

d_output  signature ; 

73 

long 

d_unique_id ; 

Listing  3.  gr  block. h 


229 

230 

private  : 

231 

int 

d_output  midtiple ; 

232 

double 

input_rate 

d„_relati  ve  rate  ; 

//  approx  output_rate  / 

The  fields  d_name  and  d_unique_id  are  unique  identifiers  (text  and  numeral,  respectively) 
for  the  block  and  can  be  used  for  debugging.  The  d_output_multiple  and 
d_relative_rate  fields  inform  the  schedule  of  the  block’s  rate  of  data  consumption  and 
generation  (see  sections  2.3.3  and  2.3.4). 

Note  that  d_input_signature,  d_output_signature,  and  d_detail  are  all  Boost  smart 
pointers,  the  former  pointing  to  gr_io_signature  objects,  the  latter  to  a 
gr_block_detail  object.  The  comments  above  highlight  the  purpose  of  the  various  fields; 
we  explain  in  more  detail  in  what  follows. 

As  seen  in  list  4,  gr_block  has  the  following  important  functions. 

Listing  4.  gr  block. h 

82 

105 

106 
122 

123 

124 

125 
157 


void  set  history  (unsigned  history)  {  d  history  =  history;  } 
virtual  void  forecast  (int  noutput_items  , 

gr_vector_int  &ninput_items  required  )  ; 
virtual  int  general_work  (int  noutput_items  , 

gr_vector_int  &ninput_items  , 
gr_vector_const_void  star  &input_items  , 
gr_vector_void_star  &output_items)  =  0; 
void  consume  (int  which _ input,  int  how _ many _ items); 


In  the  remainder  of  this  section,  we  detail  each  of  these  functions.  It  is  useful  to  think  of 
the  process  of  writing  a  new  block  as  a  “two-way  street”  between  our  block  and  the  GNU 
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Radio  internals,  collectively  referred  to  herein  as  the  scheduler.  The  scheduler  gives  us 
data  from  the  USRP,  on  which  our  block  performs  signal  processing.  In  turn,  our  block 
tells  the  scheduler  how  much  processing  we’ve  done  and  how  much  more  input  we  need  to 
produce  more  output,  so  the  scheduler  knows  what  data  it  no  longer  needs  to  store,  how 
much  buffer  memory  to  allocate,  when  to  schedule  our  block  to  execute  next,  etc.  This,  in 
turn,  determines  when  the  scheduler  will  invoke  our  block  next  and  with  how  much  input. 

2.3.1  Function:  general _ work() 

The  general_work()  function  plays  a  central  role  in  new  block  creation.  It  implements  the 
process  of  converting  the  input  stream(s)  to  the  output  stream(s).  Table  1  explains  the 
purpose  of  the  arguments  to  this  function. 


Table  1.  Arguments  of  general_work(). 


Argument 

Purpose 

noutput_items 

Number  of  output  items  to  write  on  each  output  stream 

ninput _ items 

Number  of  input  items  available  on  each  input  stream 

input_items 

Vector  of  pointers  to  elements  of  the  input  stream(s),  i.e., 
element  i  of  this  vector  points  to  the  ith  input  stream 

output  items 

Vector  of  pointers  to  elements  of  the  output  stream(s),  i.e., 
element  i  of  this  vector  points  to  the  ith  output  stream 

Recall  that  we  stated  earlier  that  a  signal  processing  block  may  have  multiple  input  and/or 
output  streams.  So,  ninput_items  is  vector  whose  ith  element  is  the  number  of  available 
items  on  the  ith  input  stream.  However,  noutput_ items  is  a  scalar,  not  a  vector,  because 
GNU  Radio  implementation  forces  the  number  of  output  items  to  write  on  each  output 
stream  to  be  the  same.  The  returned  value  of  general_work()  is  the  number  of  items 
actually  written  to  each  output  stream,  or  -1  on  end  of  file  (EOF). 

To  create  a  block,  we  simply  define  how  to  create  output_items  from  input_items, 
assuming  that  all  parameters  are  provided  to  us.  That  is,  we  implement  the  signal 
processing  algorithm  in  this  method.  The  scheduler  invokes  the  concrete 
implementation  of  general_work  with  the  appropriate  parameters.  We  do  not  have  to 
explicitly  invoke  general _work;  we  only  need  to  define  it. 

After  we  have  defined  general_work  for  our  custom  signal  processing  block,  we  need  to 
invoke  the  consume ()  function  to  indicate  to  the  scheduler  how  many  items 
(how_many_items)  have  been  processed  on  each  (which_input)  input  stream.  Recall  that 
the  scheduler  is  providing  us  all  the  appropriate  parameters  for  us  to  write  our  own  block; 
we  need  to  provide  feedback  to  the  scheduler  so  it  knows  which  elements  have  been  used, 
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so  it  can  mark  appropriate  memory  for  deletion  or  reuse,  and  update  pointers  to  point  to 
new  data.  This  feedback  of  our  signal  processing  progress  is  provided  to  the  scheduler  via 
the  consume  function. 

2.3.2  Functions:  forecast()  and  set _ history() 

The  forecast  ()  function  is  our  way  of  telling  the  scheduler  our  estimate  of  the  number  of 
input  elements  that  will  be  needed  to  create  an  output  element.  For  example,  a  decimating 
filter  of  order  5  requires  five  inputs  to  produce  one  output.  The  key  argument  is 
ninput_items_required,  which  is  a  vector  specifying  the  number  of  input  items  required 
on  each  input  stream  to  produce  noutput_items  number  of  outputs  on  each  output 
stream.  In  some  cases,  like  the  decimating  filter  of  specified  order,  we  may  know  this 
number  exactly.  In  other  cases,  we  may  need  to  estimate  it.  When  the  scheduler 
determines  it  is  ready  to  handle  noutput_ items  more  items  on  the  output  streams,  it 
invokes  the  forecast  function  to  determine  whether  or  not  we  have  enough  input  items  to 
call  general_work.  For  example,  an  interpolator  will  produce  multiple  outputs  for  a  single 
input,  while  a  decimator  will  produce  a  single  output  for  multiple  inputs.  If  we  have  a 
10-to-l  decimator  but  only  9  inputs  are  available,  the  scheduler  will  not  call  general_work 
if  the  forecast  function  is  correctly  implemented. 

There  is  an  important  distinction  to  make  here.  Another  common  requirement,  such  as  for 
a  moving  average  filter  that  averages  the  five  most  recent  inputs  to  produce  a  single 
output,  is  the  need  to  process  multiple  input  samples  to  yield  a  single  output  sample.  It 
may  seem  as  if  our  forecast  function  should  specify  this.  However,  in  this  case,  while  the 
moving  average  filter  uses  five  inputs  to  produce  one  output,  it  does  not  require  five  new 
inputs;  it  still  only  consumes  a  single  new  input  to  produce  a  single  new  output.  So,  our 
forecast  function,  in  this  case,  would  still  call  for  a  one-to-one  relation  of  noutput_items 
to  ninput_items_required.  In  this  case,  the  fact  that  we  need  the  five  most  recent  inputs 
would  be  specified  to  GNU  Radio  via  the  set_history  (5)  function  call. 

2.3.3  Field:  d _ output _ multiple 

By  now,  we  have  seen  that  the  GNU  Radio  scheduler  is  responsible  for  invoking 
general_work  and  forecast.  The  forecast  ()  function  allows  us  to  signal  to  the 
scheduler  to  invoke  our  general_work  function  only  when  a  sufficient  number  of  input 
elements  are  in  the  input  buffer.  But  we  have  not  seen  any  such  mechanism  to  control  the 
number  of  outputs  being  produced.  Recall  the  argument  noutput_ items  in  the  forecast 
function.  It  it  specified  by  the  scheduler  and  contains  how  many  output  items  to  produce 
on  each  stream.  While  we  cannot  directly  set  this  value  (it  is  under  the  scheduler’s 
control),  there  is  a  variable  d_output_multiple  that  tells  the  scheduler  that  the  value  of 
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noutput_items  must  be  an  integer  multiple  of  d_output_multiple.  In  other  words,  the 
scheduler  only  invokes  forecast!)  and  general_work()  if  noutput_ items  is  an  integer 
multiple  of  d_output_multiple.  The  default  value  of  d_output_multiple  is  1.  Suppose, 
for  instance,  we  are  interested  in  generating  output  elements  only  in  64-element  chunks.  By 
setting  d_output_multiple  to  64,  we  can  achieve  this,  but  note  that  we  may  also  get  any 
multiple  of  64,  such  as  128  or  192,  instead. 

The  following  functions  allow  us  to  set  and  get  the  value  of  d_output_multiple: 


void  gr_block: : set_output_multiple  (int  multiple); 

int  output_multiple  () ; 

2.3.4  Field:  d _ relative _ rate 

Recall  our  description  of  block  creation  as  involving  a  ’’two-way  communication”  with  the 
scheduler.  The  d_relative_rate  field  is  the  way  we  tell  the  scheduler  the  approximate 
ratio  of  output  rate  to  input  rate  at  which  we  expect  our  signal  processing  algorithm  to 
operate.  The  key  purpose  of  d_relative_rate  is  to  allow  the  scheduler  to  optimize  its  use 
memory  and  timings  of  invocation  of  general_work.  For  many  blocks,  d_relative_rate 
is  1.0  (the  default  value),  but  decimators  will  have  a  value  less  than  1.0  and  interpolators 
greater  than  1.0. 

The  functions  used  to  set  and  get  the  value  of  d_relative_rate  are  given  below: 


void  gr_block: : set_relative_rate  (double  relative_rate) ; 
double  relative_rate  () ; 


3.  Creation  of  SWIG  Interfaces 


In  what  follows,  we  strongly  urge  the  reader  to  download  the  hie 

gr-howto-write-a-block-3 . 3 . 0 .  tar .  gz  from  ftp.gnu.org/gnu/gnuradio/  and  extract  the 
archive.  This  archive  contains  sample  code  related  to  creating  a  new  block,  which  we  refer 
to. 

3.1  Naming  Conventions 

Before  getting  into  the  details  of  block  creation,  let  us  start  with  a  note  about  some 
important  naming  conventions. 


3.1.1  Block  Names 


After  we  create  our  new  block,  the  only  way  we  can  use  it  in  GNU  Radio  is  to  create  a 
Python  script,  which  loads  the  package/modulc  containing  the  block,  and  then  connect  our 
block  into  a  GNU  Radio  flowgraph,  as  usual.  This  would  involve  Python  code  resembling 
the  following: 


from  package_name  import  module_name 
nb  =  module  name. block  name() 


There  is  a  key  coupling  between  the  module  and  block  names  that  we  invoke  in  Python, 
and  the  names  used  in  coding  blocks  in  C++.  Namely,  GNU  Radio  expects  that  all  C++ 
source  and  header  hies  are  in  the  form  [module  name]  [block  name]. h  and 
[module_name]_[block_name].cc  .  That  is,  if  we  decided  to  name  our  C++  class 
newModule_newBlock,  then  GNU  Radio’s  build  system  would  make  our  block  available 
from  Python  in  module  “newModule”  and  with  block  name  ’’newBlock”.  So  while  in  theory 
there  is  no  need  for  such  a  coupling  of  naming  schemes,  in  practice,  such  a  coupling  does 
exist. 

3.1.2  Boost  Pointers 

We  have  mentioned  earlier  that  all  pointers  to  GNU  Radio  block  objects  must  use  Boost 
shared  pointers  not  “regular”  C++  pointers.  In  other  words,  if  we  create  a  new  C++ 
signal  processing  block  called  “newModule_newBlock”,  then  GNU  radio’s  internal 
implementation  will  not  work  if  we  use  a  pointer  to  newBlock  newFunction  in  our  code. 

In  other  words,  the  command 


newModule  newBlock*  nb  =  new  newModule  newBlock () 


is  not  permitted.  This  is  enforced  by  making  all  block  constructors  private  and  ensures 
that  a  regular  C++  pointer  can  never  point  to  a  block  object.  But  if  the  constructor  is 
private,  how  do  we  create  new  instance  of  our  block?  After  all,  we  need  some  sort  of  public 
interface  for  creating  new  block  instances.  The  solution  is  to  declare  a  “friend  function,” 
which  acts  as  a  surrogate  constructor.  This  is  achieved  by  first  declaring  a  friend  function 
of  the  class,  so  it  has  access  to  all  private  members,  including  the  private  constructor.  This 
friend  function  invokes  the  private  constructor  and  returns  a  smart  pointer  to  it.  Second, 
we  invoke  this  friend  function  every  time  we  want  to  construct  a  new  object. 
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Suppose  the  name  of  our  new  signal  processing  block  is  newModule_newBlock_cc.  Then, 
we  would  create  a  hie  newModule_newBlock_cc .  cc,  in  which  we  would  include  the 
following  function  declaration: 


typedef  boost: : shared_ptr<newModule_newBlock_cc>  newModule_newBlock_cc_sptr ; 
friend  newNodule_newBlock_cc_sptr  newModule_make_newBlock_cc () 


Now,  the  function  newModule_newBlock_make_cc()  has  access  to  private  members  of  the 
class  newModule_newBlock_cc.  So  from  within  this  function,  we  call  the  private 
constructor  of  newModule_newBlock_cc,  in  order  to  create  a  new  instance  of  our  block. 
The  final  step  is  to  cast  the  returned  pointer’s  data  type  from  a  raw  C++  pointer  to  a 
smart  pointer 


newNodule_newBlock_cc_sptr  newModule_make_newBlock_cc ()  ()  { 

return  newNodule_newBlock_cc_sptr  (new  newModule_newBlock_cc() ) ; 

} 

The  private  constructor  (which  we  cannot  invoke  directly),  on  the  other  hand,  would  look 
something  like  this. 


newNodule_newBlock_cc  ()  { 

gr_block  ( ‘ ‘newBlock_cc" , 

gr_make_io_signature  (1,  1,  sizeof  (gr_complex) ) , 
gr_make_io_signature  (1,  1,  sizeof  (gr_complex) ) 

) 

} 


So  to  summarize,  the  private  constructor  is  actually  creating  a  new  gr  block  object.  The 
“friend”  constructor,  the  public  interface  to  the  private  constructor,  acts  as  a  surrogate  by 
wrapping  the  new  object  created  by  the  private  constructor  into  a  Boost  shared  pointer. 
This  convoluted  procedure  guarantees  that  all  pointers  to  blocks  are  Boost  smart  pointers. 
The  public  interface  to  creating  objects  is  not  the  object  constructor 
newModule_newBlock_cc,  but  rather  the  “surrogate”  constructor 
newModule_newBlock_make_cc. 

Then,  in  our  code,  we  must  create  a  new  block  object  using  the  code 
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newModule_newBlock_cc_sptr  nb  =  newModule_make_newBlock_cc () 


Here  is  an  important  point:  if  one’s  block  name  is  newModule_newBlock_cc,  then  the  name 
of  the  shared  pointer  to  this  block  MUST  be  newModule_newBlock_cc_sptr.  Any  other 
choice,  such  as  nb_nf  _sptr,  would  lead  to  the  block  not  working  properly.  This  has 
nothing  to  do  with  C++,  since  any  valid  name  will  work.  Rather,  when  this  C++  block  is 
invoked  from  Python  in  a  GNU  Radio  program,  GNU  Radio  expects  the  shared  pointer 
name  to  follow  directly  from  the  block  name  with  an  _sptr  added  on,  or  else  it  will 
complain  that  it  cannot  find  the  block. 

Also,  the  surrogate  constructor  that  creates  a  shared  pointer  to  newModule_newBlock_cc 
must  have  signature 


newModule_newBlock_cc_sptr  newModule_make_newBlock_cc() 


Note  the  presence  of  the  word  “make”  between  the  newModulc  and  newBlock  words.  Thus, 
consider  the  naming  of  shared  pointers  to  block  objects,  as  well  as  the  friend  functions 
(surrogate  constructors)  that  create  them,  not  as  a  convention  but  as  rule  to  be  followed. 

3.2  SWIG  Interface  File 


Once  we  have  created  our  .cc  and  .h  hies,  the  next  step  is  to  create  the  SWIG  (.i)  hie,  so 
we  can  expose  our  new  block  to  Python.  SWIG  is  used  to  generate  the  necessary  “glue,”  as 
it  is  often  called,  to  allow  Python  and  C++  to  “stick”  together  in  a  complete  GNU  Radio 
application.  The  purpose  of  the  .i  hie  is  to  tell  SWIG  how  it  should  go  about  creating  this 
glue. 

A  .i  hie  is  very  similar  to  a  .h  hie  in  C++  in  that  it  declares  various  functions.  However, 
the  .i  hie  only  declares  the  functions  that  we  want  to  access  from  Python.  As  a  result,  the 
.i  hie  is  typically  quite  short  in  length. 


We  illustrate  an  actual  .i  hie  in  list  5,  called  gr_multiply_const_f  f  .  i. 


1 

2 

3 

4 

5 

6 

7 
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Listing  5.  gr  multiply  const  ff.i 

/* 

*  GR__SWIG_BLOCK_MAGIC is  a  function  which  allows  us  to  invoke  our  block 

*  gr_multiply_const_ff_from  Python  as  gr  .  multiply_const_cc  () 

*  Its  first  argument,  ’gr’,  will  become  the  package  prefix. 

*  Its  second  argument  ’ multiply_const_ff  ’  will  become  the  object  name. 
*/ 

GR  SWIG  BLOCK  MAGIC  (gr  ,  multiply_const_ff) 


11 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 


/* 

*  gr_make_multiply_const_ff  is  the  surrogate  constructor 

*  i.e.  the  friend  function  of  class  gr_multiply_const_ff 
*/ 

gr_multiply_const_ff  sptr  gr  rnake_multiply  const  _ff  (float  k)  ; 


class  gr  multiply _const_ff  :  public  gr_sync_block 

{ 

private  : 

gr_multiply_const_ff  (float  k)  ;  //  the  ’true’,  private  constructor 

public  : 

float  k  ()  const  {  return  d_k;  } 
void  set  k  (float  k)  {  d_k  =  k;  } 

}; 


There  are  some  important  aspects  to  note  from  the  above  choices  of  names.  First,  the  fact 
that  we  have  invoked  GR_SWIG_BLOCK_MAGIC  with  parameters  “gr”  and 
“mult  iply_ const _ff  ”  has  direct  relevance  to  how  we  invoke  the  block  from  Python. 
Practically,  this  means  that  in  Python,  when  we  seek  to  invoke  our  blocks,  we  would  first 
use  the  command 


import  gr 


When  we  wish  to  instantiate  our  block,  we  would  use  the  Python  command 


block  =  gr .multiply_const_f f () 


In  summary,  from  within  Python,  gr  is  a  package  and  mult  iply_ const _ff  is  a  function 
within  this  package.  The  way  we  have  created  the  .i  file  specifies  the  particular  names  that 
Python  ascribes  to  the  package  (gr)  and  function  (multiply_const_f f ). 


4.  Installation  of  Blocks 


4.1  Directory 

The  next  step  involves  placing  various  files  in  the  correct  locations  to  ensure  a  successful 
build.  We  assume  that  we  have  finished  writing  all  the  necessary  files  and  now  make  our 
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new  blocks  accessible  from  Python.  In  this  section,  we  outline  the  key  steps  needed  to 
build  new  signal  processing  applications  in  GNU  radio. 

A  sample  block  is  available  from  the  GNU  Radio  online  package  archive  [?],  where  each 
block  is  version  numbered  as  X.Y.Z  to  correspond  to  the  analogous  version  of  GNU  Radio. 
Download  and  unpack  this  block  to  a  directory  of  your  choice,  e.g.,  “newBlock”.  The 
directory  structure  and  significance  of  each  folder  is  explained  in  table  2. 


Table  2.  Contents  of  newBlock  directory  in  GNU  Radio. 


Directory 

Contents 

/home/user  /  newBlock 

Top  level  Makefile,  documentation 

/home  /  user  /  newBlock/config 

Files  for  GNU  Autotools 

/home  /  user  /  newBlock/src 

Top  level  folder  for  C++  and  Python  files 

/home  /  user  /  newBlock/src/lib 

Folder  for  C++  source/header  files 

As  we  write  our  own  blocks,  keep  in  mind  that  all  hies  (.h,  .cc,  and  .i)  for  the  new  signal 
processing  block  should  go  in  the  newBlock/src/lib  directory. 

4.2  Preparing  Makefile. am  for  Autotools 

The  final  step  before  compilation  is  to  edit  the  Makefile. am  file  (located  in  the  previous 
example  in  the  root  directory,  i.e.,  /home/user/newBlock).  Makefile,  am  specifies  which 
libraries  to  build,  the  source  files  that  comprise  those  libraries,  and  the  appropriate  flags  to 
use.  This  file  contains  relevant  information  to  configure  the  build  process  that  is  to  follow 
to  correctly  compile  our  code.  Open  this  file  and  edit  two  sections.  The  first,  shown  below, 
identifies  the  name  of  SWIG’s  .i  file: 


#  Specify  the  .i  file  below 
LOCAL  IFILES  =  newModule.i 


The  next  tells  SWIG  which  files  to  build  and  what  to  name  them  for  use  by  Python: 

BUILT_SOURCES  =  \ 

newModule.cc  \ 

newModule .py 

The  next  set  of  commands  ensures  that  our  new  block’s  Python  code  is  installed  in  the 
proper  location. 
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ourPython_PYTHON  = 
newModule .py 

ourlib  LTLIBRARIES  =  newModule. la 


\ 


The  next  set  of  commands  specify  which  source  files  are  included  in  the  shared  library  that 
SWIG  exposes  to  Python: 


_newModule_la_SOURCES  =  \ 

newModule. cc  \ 

newModule  newBlock  cc.cc 


The  final  set  of  commands  specify  key  flags  to  ensure  that  our  new  signal  processing  block 
shared  library  compiled  and  linked  correctly  against  SWIG  and  the  C++  standard  library: 


_newModule_la_LDFLAGS  =  -module  -avoid-version 
_newModule_la_LIBADD  =  \ 

-lgrswigrunpy  \ 

-lstdc++ 

newModule.cc  newModule. py:  newModule. i  $ (ALL_IFILES) 

$ (SWIG)  $ (SWIGCPPPYTHONARGS)  -module  newModule  -o  newModule. cc  $< 
grinclude_HEADERS  =  \ 

newModule_newBlock_cc . h 

4.3  Installation 

After  we  finish  coding  our  block,  we  need  to  install  it.  Fortunately,  this  process  is  made 
easy  by  the  included  makefile  in  the  archive  downloaded  earlier.  With  the  editing  of  the 
Makefile .  am  file  as  above,  we  are  now  ready  to  build  our  new  block.  Simply  use  the 
following  commands: 


. /bootstrap 

./configure  — pref ix=prefix 
make 

sudo  make  install 

sudo  touch  install_path/ package_name/ _ init _ .py 


Here,  “prefix”  is  the  root  of  our  GNU  radio  installation  (default  is  /usr/local).  Also, 
“install  path”  is  the  directory  where  our  package  is  being  installed  (default  is 


14 


prefix /lib /Python/ Python-version /site-packages,  where  Python-version  is  the  version  of 
Python  being  used).  Finally,  ”package_name”  is  the  name  of  the  Python  package  under 
which  our  block  will  be  available.  This  would  have  been  specified  in  Makefile .  am  by  us 

during  build  time,  so  we  just  enter  that  name  here.  The  creation  of  an _ init _ .py  hie  is 

necessary  since  Python  expects  every  directory  containing  a  package  to  have  this  hie. 

If  subsequently  we  make  changes  to  our  code,  we  can  repeat  the  above  steps  but  omit  the 
bootstrap  and  configure  steps. 


5.  Usage  of  Blocks 

5.1  Invoking  from  Python 

Our  hnal  step  is  to  use  our  new  block  from  Python  as  part  of  a  GNU  Radio  howgraph. 
This  is  easy  using  the  following  commands:. 

from  gnuradio  import  newModule 
block  =  newModule .newBlock  cc  () 


5.2  Debugging 

The  challenge  of  debugging  our  new  block  is  that  we  are  not  executing  C++  code  directly. 
Rather,  our  block,  comprised  of  C++  code,  is  loaded  dynamically  into  Python  and 
executed  “through”  a  Python  process.  Therefore,  the  most  convenient  debugging  option 
involves  inserting  print  statements  through  the  block  source  code  to  monitor  its  status 
during  execution.  For  those  familiar  with  GDB  (and  often,  many  graphical  debuggers  use 
GDB  under  the  covers),  the  following  code  can  be  used: 


from  gnuradio  import  newModule 

import  os  #package  providing  blocking  function 

print  ’My  process  id  is  (pid  =  °/„d)  ’  %  (os .  getpidO  , ) 

raw_input  (’Please  attach  GDB  to  this  process  ID,  then  hit  enter:  ’) 

#  now  continue  using  our  block 

block  =  newModule ,newBlock_cc() ; 
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The  idea  of  this  code  is  simply  to  discover  the  process  ID  of  the  Python  process,  which 
invokes  our  new  block,  and  then  in  another  terminal,  have  GDB  attach  to  this  process  ID. 
Now,  GDB  can  be  used  as  usual  (to  set  breakpoints,  watch  points,  etc.)  When  we  have 
configured  GDB  as  we  like,  we  can  return  to  the  terminal  executing  the  Python  process, 
and  hit  Enter  to  have  it  proceed. 

5.3  Simplifying  the  Build 

As  we  have  mentioned  previously,  there  are  several  caveats  involved  in  the  creation  of  a 
new  signal  processing  block.  Beyond  just  writing  the  C++  code,  we  must  create  a 
Makefile. am  file  and  SWIG  .i  file,  and  be  careful  in  the  naming  of  various  files  and 
functions  so  as  to  adhere  to  GNU  Radio’s  naming  rules.  These  steps  are  a  “one-time  cost” 
associated  with  writing  a  new  block.  Then,  we  have  to  ensure  all  files  are  placed  in  the 
correct  place,  and  then  invoke  a  series  of  commands  to  compile,  build,  and  deploy  our 
application.  These  latter  steps  are  a  ’’recurring  cost,”  which  we  must  incur  each  time  we  go 
through  the  debug-build-test  cycle.  Overall,  the  process  of  building  and  deploying  the 
block  can  be  time-consuming  and  error-prone.  To  allow  us  to  focus  on  creating  new  signal 
processing  blocks  in  C++  and  avoid  dealing  directly  with  the  complexities  of  the  build 
process  and  naming  rules,  we  have  created  a  script  in  Python.  After  the  user  has  written  a 
new  block  in  C++,  this  script  automates  the  rest  of  the  process,  ensuring  that  all  naming 
rules  are  adhered  to  (and  renaming  accordingly  when  necessary)  and  all  packages  are 
properly  built  and  usable  from  Python.  The  script  is  given  in  the  appendix  B. 


6.  Conclusion 


In  this  report,  we  have  provided  the  details  of  how  to  create  a  new  signal  processing  block 
using  GNU  Radio.  We  have  highlighted  important  naming  conventions;  surveyed  the 
important  functions  to  be  overridden  in  gr_block,  such  as  general_work  and  forecast; 
and  illustrated  the  importance  of  Boost  smart  pointers.  Finally,  we  have  discussed  how  to 
compile  a  block,  deploy  it,  and  invoke  it  from  Python. 
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A.  The  gr _ block. h  Script 


/*  C++  -*-  */ 

/* 

*  Copyright  2004,2007,2009,2010  Free  Software  Foundation  ,  Inc. 

* 

*  This  file  is  part  of  GNU  Radio 

* 

*  GNU  Radio  is  free  software ;  you  can  redistribute  it  and/or  modify 

*  it  under  the  terms  of  the  GNU  General  Public  License  as  published  by 

*  the  Free  Software  Foundation;  either  version  3,  or  (at  your  option) 

*  any  later  version. 

* 

*  GNU  Radio  is  distributed  in  the  hope  that  it  will  be  useful, 

*  but  WITHOUT  ANY  WARRANTY;  without  even  the  implied  warranty  of 

*  MERCHANTABILITY  or  FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the 

*  GNU  General  Public  License  for  more  details. 

* 

*  You  should  have  received  a  copy  of  the  GNU  General  Public  License 

*  along  with  GNU  Radio;  see  the  file  COPYING.  If  not,  write  to 

*  the  Free  Software  Foundation  ,  Inc  .  ,  51  Franklin  Street  , 

*  Boston,  MA  02110-1301,  USA. 

*/ 

#ifndef  INCLL'DIII)  GR  BLOCK  II 
#define  INCLUDED  GR  BLOCK  II 

^include  <gr  basic  block  .  h> 

/*  ! 

*  \brief  The  abstract  base  class  for  all  ’terminal’  processing  blocks. 

*  \ingroup  base_blk 

* 

*  A  signal  processing  flow  is  constructed  by  creating  a  tree  of 

*  hierarchical  blocks  ,  which  at  any  level  may  also  contain  terminal  nodes 

*  that  actually  implement  signal  processing  functions .  This  is  the  base 

*  class  for  all  such  leaf  nodes. 

*  Blocks  have  a  set  of  input  streams  and  output  streams.  The 

*  input_signature  and  output_signature  define  the  number  of  input 

*  streams  and  output  streams  respectively  ,  and  the  type  of  the  data 

*  items  in  each  stream. 

* 

*  Although  blocks  may  consume  data  on  each  input  stream  at  a 

*  different  rate,  all  outputs  streams  must  produce  data  at  the  same 

*  rate.  That  rate  may  be  different  from  any  of  the  input  rates. 

* 

*  User  derived  blocks  override  two  methods,  forecast  and  general_work , 

*  to  implement  their  signal  processing  behavior .  forecast  is  called 

*  by  the  system  scheduler  to  determine  how  many  items  are  required  on 

*  each  input  stream  in  order  to  produce  a  given  number  of  output 

*  items . 
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51  * 

52  *  general_work  is  called  to  perform  the  signal  processing  in  the  block. 

53  *  It  reads  the  input  items  and  writes  the  output  items. 

54  */ 

55 

56  class  gr  block  :  public  gr  basic  block  { 

57 

58  public : 

59 

60  ///  Magic  return  values  from  general_work 

61  enum  { 

62  WORKCAT  J  EO_PliODT  ICE  =  -2, 

63  WCBKECNE  =  -1 

64  }; 

65 

66  enum  tag_propagation  policy_t  { 

67  TPP  DONT  =  0  , 

68  TPP  Abb  TO  ALL  =  1 , 

69  TPP_ONE_TO_ONE  =  2 

70  }; 

71 

72  virtual  ~gr_block  ()  ; 

73 

74  /*  / 

75  *  Assume  block  computes  y_i  =  f(x_i,  x_i  —  l,  x_i  —  2,  x_i  —  3...) 

76  *  History  is  the  number  of  x_i ’s  that  are  examined  to  produce  one  y_i. 

77  *  This  comes  in  handy  for  FIR  filters  ,  where  we  use  history  to 

78  *  ensure  that  our  input  contains  the  appropriate  "history  "  for  the 

79  *  filter.  History  should  be  equal  to  the  number  of  filter  taps. 

80  */ 

81  unsigned  history  ()  const  {  return  d  history  ;  } 

82  void  set  history  (unsigned  history)  {  d  history  =  history;  } 

83 

84  /*  / 

85  *  \brief  Return  true  if  this  block  has  a  fixed  input  to  output  rate. 

86  * 

87  *  If  true,  then  fixed_rate_in_to_out  and  fixed_rate_out_to_in  may  be  called 

88  */ 

89  bool  fixed_rate  ()  const  {  return  d_fixed  rate  ;  } 

90 

91  //  - 

92  //  override  these  to  define  your  behavior 

93  //  - 

94 

95  /*  / 

96  *  \brief  Estimate  input  requirements  given  output  request 

97  * 

98  *  \param  noutput_items  number  of  output  items  to  produce 

99  *  \param  ninput_items_required  number  of  input  items  required  on  each 

input  stream 

100  * 

101  *  Given  a  request  to  product  \p  noutput_items ,  estimate  the  number  of 

102  *  data  items  required  on  each  input  stream.  The  estimate  doesn’t  have 
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103 

*  to  be  exact,  but  should  be  close. 

104 

*/ 

105 

virtual  void  forecast  (int  noutput_items  , 

106 

gr_vector_int  &ninput_items  required  )  ; 

107 

108 

/*  / 

109 

*  \brief  compute  output  items  from  input  items 

110 

* 

111 

*  \param  noutput_items  number  of  output  items  to  write  on  each  output 

stream 

112 

*  \param  ninput_items  number  of  input  items  available  on  each  input 

stream 

113 

*  \param  input_items  vector  of  pointers  to  the  input  items  ,  one 

entry  per  input  stream 

114 

*  \param  output_items  vector  of  pointers  to  the  output  items  ,  one 

entry  per  output  stream 

115 

* 

116 

*  \returns  number  of  items  actually  written  to  each  output  stream,  or  — 1  on 

EOF. 

117 

*  It  is  OK  to  return  a  value  less  than  noutput_items  .  — 1  <=  return  value 

<=  noutput_items 

118 

* 

119 

*  general_work  must  call  consume  or  consume_each  to  indicate  how  many  items 

120 

*  were  consumed  on  each  input  stream. 

121 

*/ 

122 

virtual  int  general  work  (int  noutput_items  , 

123 

gr _ vector _ int  &ninput _ items  , 

124 

gr_vector  const_void_star  &input  items  , 

125 

gr_vector_void_star  &output_items)  =  0; 

126 

127 

! 

128 

*  \brief  Called  to  enable  drivers,  etc  for  i/o  devices. 

129 

* 

130 

*  This  allows  a  block  to  enable  an  associated  driver  to  begin 

131 

*  t.ransfering  data  just  before  we  start  to  execute  the  scheduler . 

132 

*  The  end  result  is  that  this  reduces  latency  in  the  pipeline  when 

133 

*  dealing  with  audio  devices,  usrps  ,  etc. 

134 

*/ 

135 

virtual  bool  start  ()  ; 

136 

137 

/ 

138 

*  \brief  Called  to  disable  drivers,  etc  for  i/o  devices. 

139 

*/ 

140 

virtual  bool  stop(); 

141 

142 

/  / 

// 

143 

144 

/*  ! 

145 

*  \brief  Constrain  the  noutput._items  argument  passed  to  forecast  and 

general_work 

146 

* 

147 

*  set_output_multiple  causes  the  scheduler  to  ensure  that  the  noutput_items 

148 

*  argument  passed  to  forecast  and  general_work  will  be  an  integer  multiple 

149 

*  of  \param  multiple  The  default  value  of  output  multiple  is  1. 
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151 
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173 

174 
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176 

177 

178 

179 

180 
181 
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183 

184 

185 

186 
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192 
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198 


*/ 

void  set_output_multiple  (int  multiple); 

int  output_multiple  ()  const  {  return  d__output_multiple ;  } 

/'■¥  ! 

*  \brief  Tell  the  scheduler  \p  how_many_items  of  input  stream  \p 

which_input  were  consumed. 

*/ 

void  consume  (int  which _ input,  int  how _ many _ items); 

! 

*  \brief  Tell  the  scheduler  \p  how_many_items  were  consumed  on  each  input 

stream . 

*/ 

void  consume  each  (int  how_many  items)  ; 

! 

*  \brief  Tell  the  scheduler  \p  how_many_items  were  produced  on  output 

stream  \p  which_output . 

* 

*  If  the  block’s  general_work  method  calls  produce,  \p  general_work  must 

return  WORK_CALLED_PRODUCE. 

*/ 

void  produce  (int  which_output  ,  int  how_many_items)  ; 

! 

*  \brief  Set  the  approximate  output  rate  /  input  rate 

* 

*  Provide  a  hint  to  the  buffer  allocator  and  scheduler . 

*  The  default  relative_rate  is  1.0 

* 

*  decimators  have  relative_rates  <  1.0 

*  interpolators  have  relative_rates  >  1.0 
*/ 

void  set  relative  rate  (double  relative  rate  )  ; 

! 

*  \brief  return  the  approximate  output  rate  /  input  rate 
*/ 

double  relative  rate  ()  const  {  return  d__relati ve  rate  ;  } 


/* 

*  The  following  two  methods  provide  special  case  info  to  the 

*  scheduler  in  the  event  that  a  block  has  a  fixed  input  to  output 

*  ratio.  gr_sync_block ,  gr_sync_decimator  and  gr_sync_interp  olator 

*  override  these.  If  you’re  fixed  rate,  subclass  one  of  those. 

*/ 

f  ! 

*  \brief  Given  ninput.  samples,  return  number  of  output  samples  that  will  be 

produced . 

*  N.B.  this  is  only  defined  if  fixed_r ate  returns  true  . 

*  Generally  speaking  ,  you  don  ’t.  need  to  override  this  . 

*/ 

virtual  int  fixed  rate__ninput_to_noutput  ( int  ninput); 
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199 

200  /*  / 

201  *  \brief  Given  noutput  samples,  return  number  of  input  samples  required  to 

produce  noutput. 

202  *  N.B.  this  is  only  defined  if  fixed_rate  returns  true  . 

203  *  Generally  speaking  ,  you  don  ’t  need  to  override  this  . 

204  */ 

205  virtual  int  fixed_rate__noutput_to_ninput  ( int  noutput); 

206 

207  /*  / 

208  *  \brief  Return  the  number  of  items  read  on  input  stream  which_input 

209  */ 

210  uint64_t  nitems_read ( unsigned  int  which  input )  ; 

211 

212  /*  / 

213  *  \brief  Return  the  number  of  items  written  on  output  stream  which_output 

214  */ 

215  uint64_t  nitems_written  ( unsigned  int  which  output )  ; 

216 

217  /*  / 

218  *  \brief  Asks  for  the  policy  used  by  the  scheduler  to  moved  tags  downstream 

219  */ 

220  tag_propagation__policy_t  tag_propagation_policy  ()  ; 

221 

222  /*  / 

223  *  \brief  Set  the  policy  by  the  scheduler  to  determine  how  tags  are  moved 

downstream . 

224  */ 

225  void  set_tag_propagation_policy  ( tag_propagation_policy_t  p)  ; 

226 

227  // 


228 

229  private  : 

230 

231  int  d_output_multiple ; 

232  double  d^relati  ve_rate  ;  //  approx  output_rate  / 

input_rate 

233  gr_block_detail_sptr  d_detail;  //  implementation  details 

234  unsigned  d  history  ; 

235  bool  d_fixed_rate  ; 

236  tag_propagation_policy_t  d_tag_propagation_policy ;  //  policy  for  moving  tags 

downstream 

237 

238  protected: 

239 

240  gr  block  (const  std  : :  string  fename , 

241  gr_io_signature_sptr  input  signature  , 

242  gr_io  signature  sptr  output  signature )  ; 

243 

244  void  set  fixed  rate  ( bool  fixed  rate)  {  cl  fixed  rate  =  fixed_rate  \  } 

245 
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/*  / 

*  \brief  Adds  a  new  tag  onto  the  given  output  buffer. 

* 

*  \param  which_output  an  integer  of  which  output  stream  to  attach  the  tag 

*  \param  abs_offset  a  uint6 4  number  of  the  absolute  item  number 

*  assicated  with  the  tag.  Can  get  from  nitems_written . 

*  \param  key  the  tag  key  as  a  PMT  symbol 

*  \param  value  any  PMT  holding  any  value  for  the  given  key 

*  \param  srcid  optional  source  ID  specifier;  defaults  to  PMT_F 

*/ 

void  add_item  tag  ( unsigned  int  which  output , 
uint64_t  abs_offset  , 

const  pmt :  :  pmt _ t  &key  , 

const  pmt :  :  pmt _ t  &value  , 

const  pmt :  :  pmt_t  &srcid=pmt  :  :PMT_F)  ; 

/ 

*  \brief  Given  a  [start, end),  returns  a  vector  of  all  tags  in  the  range. 

* 

*  Range  of  counts  is  from  start  to  end  —  1. 

* 

*  Tags  are  tuples  of: 

*  (item  count,  source  id,  key,  value) 

* 

*  \param  v  a  vector  reference  to  return  tags  into 

*  \param  which_input  an  integer  of  which  input  stream  to  pull  from 

*  \param  abs_start  a  uint6 4  count  of  the  start  of  the  range  of  interest 

*  \param  abs_end  a  uint.6)  count  of  the  end  of  the  range  of  interest 

*/ 

void  get_tags_in  range(  std  :  :  vector<pmt :  :  pmt_t>  &v  , 

unsigned  int  which  input  , 
uint64_t  abs_start  , 
uint64_t  abs_end )  ; 

! 

*  \brief  Given  a  [start, end),  returns  a  vector  of  all  tags  in  the  range 

*  with  a  given  key . 

* 

*  Range  of  counts  is  from  start  to  end  —  1. 

* 

*  Tags  are  tuples  of: 

*  (item  count,  source  id,  key,  value) 

* 

*  \param  v  a  vector  reference  to  return  tags  into 

*  \param  which_input  an  integer  of  which  input  stream  to  pull  from 

*  \param  abs_start  a  uint6f  count  of  the  start  of  the  range  of  interest 

*  \param  abs_end  a  uint.6)  count  of  the  end  of  the  range  of  interest 

*  \param  key  a  PMT  symbol  key  to  filter  only  tags  of  this  key 

*/ 

void  get_tags_in  range(  std  :  :  vector<pmt :  :  pmt_t>  &v  , 

unsigned  int  which  input  , 
uint64_t  abs_start  , 
uint64_t  abs_end  , 
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const  pmt : :  pmt  t  &key )  ; 
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//  These  are  really  only  for  internal  use,  but  leaving  them  public  avoids 
//  having  to  work  up  an  ever— varying  list  of  friends 

public  : 

gr  _block_detail  sptr  detail  ()  const  {  return  d  detail;  } 

void  set_detail  ( gr  block  _detail_sptr  detail)  {  d  detail  =  detail;  } 

}; 


typedef  std  ::  vector <gr__block_sptr>  gr„block__vector_t ; 
typedef  std  : :  vector  <gr_block_sptr  > : :  i  t  e  r  at  or  gr_block  viter _t  ; 

inline  gr  _block_sptr  cast_to_block__sptr  ( gr_basic_block  sptr  p) 

{ 

return  boost  : :  dynamic_pointer  cast<gr_block  ,  gr  basic__block  >(p)  ; 

} 


std  : :  ostream& 

operator  «  ( std  :  :  ostream&  os,  const  gr_block  *m)  ; 
#e  n  d  i  f  /*  INCLUDED_GR_BLOCK_H  *  / 
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B.  The  blockWizard.py  Script 


#! / usr /bin/env  python 

#This  code  simplifies  the  process  of  writing  new  blocks.  Simply  download  the 
archive  ’  gr— howto— write— a— block  —  3.3.0.  tar .  gz"  from 
#ftp  ://  ftp  .  gnu  ■  or  g  /  gnu/ gnuradio/gr—  howto—  write— a—  block  —  3 .  3 .  0 .  tar  .  gz  ,  extract 
it  to  a  directory  " topdir  ", 

#and  create  your  custom  block  in  C++  ,  placing  it  in  top  dir / src / lib  .  Then 

run  this  script . 

#The  user  only  needs  to  implement  the  block  ,  for  example 

#p  articularly  "  general_work  "  and  "forecast"  functions .  It  handles  installation 
of  shared  library  , 

#and  ensures  various  naming  "conventions"  (really  rigid  rules),  such  as  name 
of  surrogate  friend  constructor  , 

#expected  by  the  build  system  are  followed .  It  handles  the  proper  creation  of 
the  swig  file  . 

import  os 
import  re 
import  sys 

print  " \n  !  !  !  " 

print  "  Thisu wizard u  helps  u build u  (  multiple  ) ,  ( signal  u processing u blocks  ,  uandu  places 
utheniu inuau  singleumoduleuofuau  singleupackage  " 
print  " Youuonly u r e ally  uneed utouuseuthiSut he u  first utimeuyouu create uaunewu block ; 
uthen  ,  li  for  u subsequent  ucodeu changes  u to u that usameu block  ,  u  j  ust  uuseumakeuandu 
sudo  umakeu  install  " 

print  "ThisuScriptuwilliideleteuolduautotoolsurelatedu  files  ufromu  t  hi  su  directory 
uandu generate unewu ones ; u i f uyouu have u any u concerns  , u back Uupu before u 
proceeding  " 

print  "  !  ! !  " 

raw  input  ( ”  Pressuenter  utoucontinue  ,  uCtrl— Cutouabort :  " ) 

print  ( "  \nu Cleaning u  f  i  1  es  L,fromu  aborted  Ll  previous  Uruns  .  .  .  " ) 

os  .  system  (  "makeu  clean  " ) 

os  .  system  ( "rmu—  rfusrc  /  lib  /Makefile  .am"  ) 

os  .  system  ( "rmu—  rfusrc /  lib  /Makefile  " ) 

os  .  system  ( "rmu—  rfusrc /  lib  /Makefile  .  in  " ) 

os  .  system  ( "rmu—  rfusrc /  lib  /.  deps  " ) 

os  .  system  ( "rmu—  rfusrc /  lib  /*.  i  "  ) 

os  .  system  (  "rmu—  rfusrc  /  lib  /Makefile  .  swig  .  gen  " ) 

src_headers  =  list  () 
src_source  =  list  () 

class_i inheritance  =  diet  () 
friend_co instructor  =  diet  () 

constructor  =  diet ()  #maps  header  files  to  the  signature  of  their  constructors 
destructor  =  diet ()  #maps  header  files  to  the  signature  of  their  destructors 
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prefix  =  raw_input  (  ’\n\nSpecifyuprefix:Lj[  prefix]/  lib  /  python  [version]  /  site- 
packages  u  (  default  u=u/usr /local )  :  u  ’ ) 
if  len(prefix)  =  0: 

prefix="  /usr  /  loc  al  " 


version  =  raw_input  (’ \n\ nSpecify  upythonu  version  :  u  ’  +  prefix  +  ’/ lib /python  [ 
version  ]  /  site  —packages  u  (  default  u=u  2.6)  :  u  ’ ) 
if  len  (version)  =  0 : 
v  e  r  s  i  o  n=  "2.6" 

install  path  =  prefix  +  "/ lib /python  "  +  version  +  "  /  site  —packages  " 
install_path_alt  =  prefix  +  "/ lib /python  ”  +  version  +  "/ dist  —packages  ”  # 
installation  may  occur  to  here  instead 

print  (  ’  \  nTheupythonucommandu to li import u  t  hi sublocku  wi  1 1  Li be  :  ufromu  [ package  name  ]  u 
import u  [module_name  ]  ’) 

package_name  =  raw^input  (  ’  En  ter  u  desired  u  package  name  u  (default  =testpackage)  :  u  ’ ) 
if  len  (package_name )  =  0: 

package_name="  testpackage  ' 

module_name  =  raw__mput(  ’  Enteru  desired  uniodule_nameu  (  default=testmodule)  :  u  ’ ) 

if  len  (module _ name)  =  0: 

module_name= "  testmodule" 

all_files=os  .  listdir  (os  .  getcwd  ()  +  ” /src  /  lib  ” ) 

#create  lists  of  the  .h  files  and  the  .  cc  files 
for  filename  in  all  files: 

#header_p  attern  =  r  e  .  compile  (’[ \w]  +  .  h  ’ ) 

#suffix_pattern  =  re  .  compile  (’ [\w] +  .  cc  ’ ) 

if  ”.h”  in  filename: 

src _ headers  .  append  (filename) 

if  ”  .  cc  ”  in  filename: 

src_source  .  append(  filename  ) 


print  (  ’  \  n\nTheupythonucommandu  to  u  create  u  thisublockuwillube:  uobj  ect  u=u  ’  + 
module_name  +  ’  .  [  block_name  ]  u  ( )  ’ ) 
i  =  0 

block_names={}  # dictionary  mapping  header  file  to  block  name 
for  filename  in  src  headers : 
i  =  i  +  1 

block_name  =  raw_input  (  ’  Enteru  desired  ublock_nameu corresponding  utoublocku 
implemented  u  inu  ’  +  filename  [: —2]  +  ’  u  (  def  ault=test_block  ’  +  str(i)  +  ’ 
,u0u for  unone ) : u ’ ) 
if  len  ( block  name )  =  0: 

block_name="  test_block  "  +  str(i) 
if  block  name  =  0: 
block  name="  " 
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block _ names  [  filename  ]  =  block _ name 


88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108 

109 

110 
111 
112 

113 

114 

115 

116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 


#figure  out  which  classes  inherit  from  which  blocks  (e.g.  from  gr_block  or 
gr_sync_block  (allow  for  helper  classes  which  do  not  inherit  at  all) 
class_dec_pattern  =  re  .  compile  (’  [\ s  ]  *  class  [\ s\w]  +  :  ’ ) 
for  filename  in  src_headers : 

f  =  open  (  os  .  getcwd  ( )  +  "/src/lib/"  +  filename,  ’r’) 
for  line  in  f : 

if  class_dec_pattern.  match ( line  )  : 

m=  re  .  search  (’ [\ s  ]  + [\w]  +  $  ’  ,  line)  #find  the  name  of  the  class 
that  is  inherited 

i  f  m: 

class  inheritance  [filename]  =  m.  group  ()  .  strip  () 
else  : 

class_inheritance  [  filename  ]  =  "" 

f .  close  () 


#figure  out  the  signature  of  the  constructor  from  each  .h  file 
#  key  idea  is  to  look  for  string  of  the  form  " filename  ("  (where 

filename  is  without  the  .  h) 
for  filename  in  src  headers : 

constructor_string="  " 

constructor  _name=filename  [:  —  2]  #everything  but  the  .h 
multi _ line=0 

f  =  open  (  os  .  getcwd  ( )  +  "/src/lib/"  +  filename,  ’r’) 

for  line  in  f : 

if  (( constructor  name  +  "(")  in  line)  or  (( constructor  name  +  "u(")  in 
line):  #this  line  contains  a  constructor  declaration 
constructor _ strin  g=  line 

if  ("public"  in  previous_line  )  or  ("private"  in  previous_line  )  or 
("protected"  in  previous_line  )  : 
constructor  string  =  previous  line  +  constructor  string 
if  in  line:  #the  constructor  declaration  is  all  on  one  line 

multi_line=0  #does  the  constructor  declaration  span  multiple 
lines  ? 
break 
else  : 

multi_line=l 

continue 

if  multi_line  =  1:  #the  constructor  declaration  is  over  multiple 
lines 

constructor  string  =  constructor  string  +  line 

if  in  line:  #look  for  end  of  this  constructor  declaration  ,  i.e 

a  semicolon 

break 
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133 

previous_line  =  line  #save  the  previous  line  for  future  use  in  case  we 

need  to  look  back 

134 

135 

constructor  [  filename  ]  =  constructor_string  #there  is  one  constructor  per 

class  obviously 

136 

137 

f  .  close  () 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

#figure  out  the  signature  of  the  destructor  from  each  .h  file 

148 

#  key  idea  is  to  look  for  string  of  the  form  "—filename  "  (where 

filename  is  without  the  .  h) 

149 

for  filename  in  src  headers : 

150 

151 

destructor_string="  " 

152 

destructor_name=filename  [:  — 2]  #everything  but  the  .h 

153 

multi _ line=0 

154 

155 

f  =  open  (  os  .  getcwd  ()  +  "/src  /lib/"  +  filename,  ’r’) 

156 

157 

for  line  in  f: 

158 

if  (  "~"  +  destructor__name )  in  line:  #this  line  contains  a  destructor 

declaration 

159 

destructor_string=line 

160 

if  ("public"  in  previous  line  )  or  ("private"  in  previous  line  )  or 

("protected"  in  previous  line  )  : 

161 

destructor  string  =  previou  saline  +  destructor_string 

162 

if  in  line:  #the  destructor  declaration  is  all  on  one  line 

163 

multi_line=0  #does  the  destructor  declaration  span  multiple 

lines  ? 

164 

break 

165 

else  : 

166 

multi  _line=l 

167 

continue 

168 

169 

if  multi  line  =  1:  #the  destructor  declaration  is  over  multiple  lines 

170 

destructor__string  =  destructor^string  +  line 

171 

if  in  line:  #look  for  end  of  this  destructor  declaration  ,  i.e 

a  semicolon 

172 

break 

173 

174 

previous_line  =  line  #save  the  previous  line  for  future  use  in  case  we 

need  to  look  back 

175 

176 

destructor  [  filename  ]  =  destructor__string  #there  is  one  constructor  per 

class  obviously 

177 
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178  f . close  () 

179 

180 
181 
182 

183 

184 

185 

186  #figure  out  the  friend  function  (from  .h  file)  acting  as  the  public  interface 

for  object  construction  (allow  for  helper  classes  that  do  not  have  this) 

187  for  filename  in  src  headers : 

188 

189 

190  friend  =  "  " 

191  target=''+_)(*&%%§^^<SJAllFrUWER0IWEAI5KJFD'' 

192  multi_line=0 

193 

194  f  =  open  ( os  .  getewd  ()  +  "/src /lib/"  +  filename,  ’r’) 

195 

196  for  line  in  f: 

197  if  "  boost  ::  shared_ptr  "  in  line:  #this  line  contains  a  typedef  ,  we  want 

to  know  the  name  of  the  alias  so  we  can  find  its  declaration 

198  target  =  line  .  strip  ()  .  split  ("u")  [  — 1][:  —  1]  #9et  the  last  word,  then 

drop  the  semicolon  of  that  last  word 

199  continue 

200 

201  if  target  in  line  : 

202  #friends  .  append  (line,  strip  ()) 

203  friend=line 

204  if  in  line:  #the  friend  declaration  is  all  on  one  line 

205  multi_line=0  #does  the  friend  declaration  span  multiple  lines  ? 

no 

206  break 

207  else  : 

208  multi_line=l 

209  continue 

210 

211  if  multi_line  =  1:  #the  friend  declaration  is  over  multiple  lines 

212  #friends  .  append  (line  .  strip  ( )  ) 

213  friend  =  friend  +  line 

214  if  in  line:  #look  for  end  of  this  friend  declaration  ,  i.e  a 

semicolon 

215  break 

216 

217  friend  constructor  [  filename  ]  =  friend 

218 

219  f . close  () 

220 
221 
222 

223  print 

224  print  ” 
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225  print  "  Blocku  will ,  ibeuimportedu inupythonu  as  :  uuuuu uuuuuuuufromu  "  +  package  name 

+  "uimportu"  +  module_name 

226 

227  for  value  in  block  names .  values  ()  : 

228  if  len  ( value)  >  1: 

229  print  ”Newu  obj  ect s  u inupythonu  will Libeuniadeuas  :  uuuuuuuuuuuobj  ect  u=u  "  + 

module_name  +  "  .  ”  +  value  +  "u()" 

230 

231 

232  print  Detected  ublocku  header  n  files  uareiuuuuuuuuuuuuuuuui  ?  sr  c _ he  a  d  e  r  s 

233  print  "  Detected  ublocku source  u  f  i  1  e  s  u are  :  i  iuuuuuuui  n  n  n  iuuuuu  "  ,  src_source 

234  print  "  Blocku  classes  u  inherit ugnuradio ubaseu  class es  uas  :  Uu "  ,  class_inheritance 

235  print  Classu  constructors  u&re  :  uu  uuuuu  uuuuu  uuuuuiiuuuuuui4.j4"  >  constructor 

236  print  Classu destructors uare : uuu uuuuuuuuuuuuuuuuuuuuumuu  ,  destructor 

237  print  "  Friend u publicu  const ructors  u are  :  uuuuuul h  juuuuuuul n  ju ”  ,  friend  constructor 

238  print  Installupathuofuthisupackageuis • uu uuuuu uuuuu uuuuu  >  install _ path 

239  print  " 

11 

240 

241  raw_input  (  ’\nPressu enter  u to u continue  ,  uoruCtrl uCutou abort  ’ ) 

242 

243 

244 

245 

246  #create  .i  file 

247  swig  i  file  =  open  ( os  .  getcwd  ( )  +  "/src/lib/"  +  module_name  +  ".i",  ’w’) 

248  swig  i  file.  write  (  ’  /*u— *—  uCfk- *—  u*/  ’ ) 

249  swig  i  file.  write  (  ’  \  n%includeu  "  gnuradio  .  i  "  ’ ) 

250  swig  i  file.  write  (  ’  \n%{  ’ ) 

251  for  filename  in  src  headers : 

252  swig_i_file  .  write  (’ \n^includeu  "  ’  +  filename  + 

253  swig_i_file.  write  (  ’  \n%}  ’ ) 

254 

255  for  filename  in  src  headers : 

256  if  ( block  names  [  filename  ]  !=  ’O’):  #check  that  this  really  corresponds  to 

a  block  implementation  and  not  helper  files 

257  swig _ i _ file  .  write  (’  \n\nGR_SWIG_BLOCK_MAGIC(  ’  +  module_name  +  ’,’  + 

block  names  [  filename  ]  +  ’);’) 

258  swig _ i _ file  .  write  (’ \n\n  ’  +  friend  constructor  [  filename  ] ) 

259 

260  #write  the  class  definition  and  constructors/ destructors  in  it 

261  swig_i_file  .  write  (’ \n\n  ’  +  ’classu’  +  filename  [:  —2]  +  ’  u  :  u  publicu  ’  + 

class _ inheritance  [  filename  ] ) 

262  swig_i_file  .  write  (’ \n{  ’ ) 

263  swig _ i _ file  .  write  (’ \n\n  ’  +  constructor  [  filename  ] ) 

264  swig_i_file  .  write  (’ \n\n  ’  +  destructor  [  filename  ] ) 

265  swig_i_file  .  write  (’ \n };’ ) 

266 

267  swig  i  file .  close  () 

268 

269 

270  #create  Makefile  .am  file  in  /src/lib 

271  Makefile_am_file  =  open  (  os  .  getcwd  ( )  +  " /src/ lib /Makefile  .am"  ,  ’w’) 
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272 

273 

274 

275 

276 

277 

278 

279 

280 
281 
282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 


Makefile_am  file  .  write  (  ’  includeu$  ( top_srcdir  )  /Makefile  .common’ ) 

Makefile_am  file  .  write  (  ’ \n\ngrinclude_HEADERS  u=u\\  ’ ) 
i  =  0 

for  filename  in  src  headers : 
i  =  i  +  1 

Makefile  am  file  .  write  (’ \n\t  ’  +  filename) 
if  (i  <  len  (  src_headers ) )  : 

Makefile_am_file  .  write  (  ’u\u  ’ ) 

Makefile  am  file  .  write  (  ’ \n\n\nTOP  SWIG  IFILES,  j—  ,\\  ’ ) 

Makefile_am  file  .  write  (  ’\n\t  ’  +  module_name  +  ’  .  i  ’ ) 

Makefile_am  file  .  write  (’ \n\n  ’  +  module_name  +  ,_pythondir_categoryu=u\\  ’ ) 
Makefilc_am_file  .  write  (’ \n\t  ’  +  package_name ) 

Makefile  am  file  .  write  (’ \n\n  ’  +  module_name  +  ’_la_swig_sourcesu=u\\  ’ ) 
i  =  0 

for  filename  in  src_source  : 
i  =  i  +  1 

Makefile  am  file  .  write  (’ \n\t  ’  +  filename) 
if  (i  <  len  (  src_source  ) )  : 

Makefile_am  file  .  write  (  ’u\u  ’ ) 

Makefile_am  file  .  write  (  ’\n\nincludeu$(  top_srcdir  )  /  Makefile  .  swig  ’) 
Makefile_am_file  .  write  (  ’  \n\nBUILT_SOURCESu=Li$  (  swig_built_sources )  ’ ) 
Makefile__am  file  .  write  (  ’\n\nno_dist_files  u=u$  (  swig_built_sources )  ’) 

Makefile_am  file  .  close  () 

#create  Makefile  .am  in  /sre/python 

Makefile_am  file  =  open  (  os  .  getewd  ( )  +  "/ src /python/ Makefile  .  am”  ,  ’w’) 

Makefile_am  file  .  write  (  ’  includeu$  ( top^sredir  )  /Makefile  .common’ ) 

Makefile_am  file  .  close  () 

#create  Makefile  .  swig  .  gen 

os  .  system  ( "  cpusrc  /lib /Makefile  .  swig  .  gen  .  '4EMPIATEU  src  /lib /Makefile  .  swig  .  gen  ” ) 
module_command  =  "  sedu— ius/testmodule/ "  +  module_name  +  " /glusrc/ lib /Makefile  . 
swig . gen " 

package  command  =  "  sedu— i  us/gnuradio  /  "  +  package  name  +  " /glusrc/ lib /Makefile  . 
swig . gen " 

os  .  system  (module _ command) 

os  .  system  (package _ command  ) 


#The  build  system  expects  source  files  to  be  of  the  form  [module_name ]_[ 
block_name ] .  h  or  [module_name ]_[ block_name ] .  cc 

#This  is  based  off  a  gnu  radio  convention .  If  our  files  are  NOT  in  this  form, 
copy  them  over  into  that  form 

#It  also  expects  the  friend  public  constructor  to  be  of  the  form  [module_name  ] 
_make_  [ block_name / 

#create  source  files  that  are  named  according  to  gnu  radio  convention  ,  i.e. 
modulename_blockname .  h  and  .  cc  (in  case  they  don  ’t  exist)  so  that  make  is 
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321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 
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343 

344 
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346 
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348 
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355 
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happy 

conforming  source  files  =  list  ( )  #list  of  source  files  conforming  to  proper 
gnu  radio  naming  convention 

swig _i _ file  =  "src/lib/"  +  module  name  +  ".i" 

Makefile  am  file  =  "  src  /  lib /Makefile  .  am" 

for  f  in  block_names .  keys  ( )  :  #loop  over  all  source  files 
make _function="  " 
ideal__make_function="  " 

filename  =  "src/lib/"  +  f 

ideal  name  =  "src/lib/"  +  module_name  +  +  block_names  [  f  ] 

if  (not  os  .  path  .  i  s  f  i  1  e  ( ideal _ name  +  ".h")):  #the  conforming,  conventional 

name  does  not  exist;  create  it 

raw__input  ( "  \nSourceunameSudounotuConformutO!  iGNUu radio u convention  !  u 

Pressuenter  utOuContinueuwithuauto— renaming . \  n" ) 

tmp  file  =  ideal  name  +  ".h" 

cmd  =  "  cpu "  +  filename  [: —2]  +  "  .  hu "  +  tmp  file 
os  .  system  (cmd) 

conforming _ source _ files  .  append  ( tmp _ file  ) 

rename  command  =  "scdu— ius/"  +  f  [ :  —  2]  +  "/"  +  module_name  +  + 

block_names  [  f  ]  +  "  / glu  "  +  tmp_file 
os  .  system  (rename _ command) 

#correct  the  friend  public  interface  name  to  conform  to  gnu  radio 
if  len  ( friend  constructor  [  f  ] )  >  0:  #this  file  has  a  friend 
constructor 

tokens=friend_cons  true  tor  [  f  ].  split  ()  #  splits  on  any  whitespace  , 
even  consecutive  whitespaces  which  are  treated  as  a  single 
whitespace  ,  which  we  want 

make  function=tokens  [  1  ].  strip  ()  #the  name  of  the  public  interface 
friend  constructor 
if  "  ()  ;  "  in  make  function  : 

make _function=make  function  [:  —  3] 
elif  "()”  in  make  function  : 

make _ function=make _ function  [:  —2] 

ideal _ make _ function  =  module _ name  +  " _ make11 

rename _ command  =  "sedu—  ius/"  +  make _ function 

ideal_make_function  +  "  / gl u "  +  tmp  file 
os  .  system  ( rename _ command) 

tmp  file  =  ideal  name  +  "  .  cc " 

cmd  =  "cpu"  +  filename  [: —2]  +  ".ccu"  +  tmp_file 
os  .  system  (cmd) 

con  form  ing  source  files  .  append  ( tmp  file  ) 
rename  command  =  "scdu—  ius/"  +  f  [ :  —  2]  +  "/"  +  module_name  +  + 

block_names  [  f  ]  +  "  / glu  "  +  tmp_filc 
os  .  system  (rename _ command) 

renamecommand  =  "scdu— ius/"  +  make  function  +  "/"  + 
ideal  _make_function  +  "/glu”  +  tmp  file 
os  .  system  (rename _ command) 

#the  swig  .i  file  needs  to  be  updated  to  reflect  this  name  change  as 


+  block_names  [  f  ] 
+  "/"  + 
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377 

378 

379 

380 

381 

382 

383 

384 
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387 

388 

389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 

401 

402 

403 

404 


well 

rename_command  =  "scdu—  ius/"  +  f  [ :  —  2]  +  "/"  +  module_name  +  + 

block_names  [  f  ]  +  "  / glu  "  +  swig_i_file 
os  .  system  (rename _ command) 

rename  command  =  "scdu— ius/"  +  make  function  +  "/"  + 
ideal_make_function  +  "/glu”  +  swig_i_file 
os  .  system  (rename _ command) 

#the  Makefile  .am  file  needs  to  be  updated  to  reflect  this  name  change 
as  well 

rename  command  =  "scdu—  ius/"  +  f  [ :  —  2]  +  "/"  +  module_name  +  + 

block_names  [  f  ]  +  "/glu"  +  Makefile_am_file 
os  .  system  (rename _ command) 

rename  command  =  "scdu—  ius/"  +  make  function  +  "  /"  + 
ideal_make_function  +  "/glu”  +  Makefile  am  file 
os  .  system  (rename _ command) 


raw  input  (  ’RequisiteLjfilesuforu  aut  ot  oolsuhaveubeenu  created  .uPressuenterutou 
continueuwithLJbootstrap  ,uconfigure  ,  LJmake ,  umakeu  in s t  a  1 1  ;uoruCtrluCutouabort 
’) 


print  (  " \n\nRunningubootstrap . ”) 

os  .  system  (  "  .  /  bootstrap  ” ) 

print  (" \n\nRunningu  configure . ") 


os  .  system  ("./ configureu — prefix=”  +  prefix) 


print  ( "  \n\nRunningumake . "  ) 

os  .  system  ( "  make"  ) 

print  ( " \n\nRunningusudoumakeu  inst  all . ") 

os  .  system  (  "  sudoumakeu  install  ' ) 

print  ( " \n\nMakingu  '  +  package_name  +  "uauproperupythonupackage . ") 

if  os  .  path  .  isdir  ( install_path  +  "/"  +  package_name)  : 

os  .  system  ( 11  sudoutouchu  "  +  install_path  +  "/"  +  package_name  +  "/ _ init 

py") 

else  : 

os  .  system  ("  sudoutouchu "  +  install_path_alt  +  "/"  +  package_name  +  "/ 
_ init _ •  py "  ) 


cleanup  =  raw_input  ( " Douyouuwant u to u erase u  all  utemporaryu makefilesuanduswigL 
files  ?u(  default=yes  )  " ) 

if  ("y”  in  cleanup)  or  ( "Y"  in  cleanup)  or  ( len  ( cleanup )  =  0): 

print  (" \n\nDoingu  final  udeanup . ") 

os  .  system  ( "  makeu  clean  "  ) 
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405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 


os  .  system  ( " rmu—  r f  u  src  /  lib  /  Makefile  " ) 

os  .  system  ( " rmu—  r f  LJ  src  /  lib  /  Makefile  .  am” ) 

os  .  system  ( " rmu—  r f  u  src  /  lib  /  Makefile  .  in  ' ) 

os  .  system  ( " rmu—  r f  u  src  /  lib  /  .deps") 

os  .  system  ( "  rmu—  r f  u  src  /  li  b  /  * .  i  " ) 

os  .  system  ( " rmu—  r f  u  src  /  lib  /  Makefile  .  swig  .  gen  "  ) 


if  len  ( conforming  source  files  )  >  0: 

cleanup  =  raw_input  ( "  Douyouuwantutou  erase  u  all  urenamed  uSOurceufiles?u( 
default=yes  )  ' ) 

if  ("y"  in  cleanup)  or  (  "Y"  in  cleanup)  or  ( len  ( cleanup )  =  0): 
#remove  re— named  source  files  ,  they  are  no  longer  needed 
for  f  in  conforming  source  files  : 
cmd  =  "rmu— rfu"  +  f 
os  .  system  (cmd) 


print  ( " \n\nYourublocku is  ureadyutouuse " ) 
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NO.  OF 

COPIES  ORGANIZATION 

1  ADMNSTR 

ELEC  DEFN  S  TECHL  INFO  CTR 

ATTN  DTIC  OCP 

8725  JOHN  J  KINGMAN  RD  STE  0944 
FT  BELVOIR  VA  22060-6218 

1  US  ARMY  RSRCH  DEV  AND  ENGRG  CMND 

ARMAMENT  RSRCH  DEV  &  ENGRG  CTR 
ARMAMENT  ENGRG  &  TECHNLGY  CTR 
ATTN  AMSRD  AAR  AEF  T  J  MATTS 
BLDG  305 

ABERDEEN  PROVING  GROUND  MD  21005-5001 

1  US  ARMY  INFO  SYS  ENGRG  CMND 
ATTN  AMSELIETD  A  RIVERA 
FT  HUACHUCA  AZ  85613-5300 

1  COMMANDER 

US  ARMY  RDECOM 

ATTN  AMSRD  AMR  W  C  MCCORKLE 

5400  FOWLER  RD 

REDSTONE  ARSENAL  AL  35898-5000 

1  US  GOVERNMENT  PRINT  OFF 

DEPOSITORY  RECEIVING  SECTION 
ATTN  MAIL  STOP  ID  AD  J  TATE 
732  NORTH  CAPITOL  ST  NW 
WASHINGTON  DC  20402 

8  US  ARMY  RSRCH  LAB 

ATTN  IMNE  ALC  HRR  MAIL  &  RECORDS  MGMT 

ATTN  RDRL  Cl  J  PELLEGRINO 

ATTN  RDRL  CIN  A  KOTT 

ATTN  RDRL  CIN  T  B  RIVERA 

ATTN  RDRL  CIN  T  G  VERMA 

ATTN  RDRL  CIN  T  P  YU 

ATTN  RDRL  CIO  LL  TECHL  LIB 

ATTN  RDRL  CIO  MT  TECHL  PUB 

ADELPHI  MD  20783-1197 
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Intentionally  Lett  Blank. 
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